@He-Pin thanks for your contribution. Could you share some more details about your use case for such a change? Thanks!

interested as well - related to the other PR, this enables an execution strategy for tools. Also, as this would require some tests cases before merging.

We are building an mcp proxy server and need some extension point.

I will share more detail once I leave the airport

@He-Pin thanks, looking forward to that! It sounds a very interesting use case! The ToolCallingManager is an interface, so it should be easy to customise to support more use cases. The DefaultToolCallingManager is just an example of a default implementation. Before changing the default implementation by introducing new APIs, I would suggest considering whether a separate implementation would work, which should guarantee full flexibility and customisations. That was the intent behind the ToolCallingManager API.

If you define your custom ToolCallingManager as a bean, Spring AI will pick it up and use it instead of DefaultToolCallingManager automatically.

@Bean
ToolCallingManager myToolCallingManager() {
    return new MyMcpToolCallingManager();
}

Inside MyMcpToolCallingManager, if there's a functionality you don't need to customise, you can also delegate to DefaultToolCallingManager.

I'm mentioning this also considering your other proposal: #2855.

yes, thanks for that , but another thing is the current ToolContext is final, and then we can only put our CTX as an special field in it, if we can subclass it , we can separate our ctx from the origin CTx

It would be better that there is an addition generic CtxData ctx parameter in the call method, but that will break the current binary compatibility.

So that's what I was thinking, we can even pass our ctx with thread local, but that's not ideal

@ThomasVitale what was the motivation for the ToolContext to be final?

8329402